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SYNCHRONIZATION OF RECURRING 
RECORDS IN INCOMPATIBLE DATABASES 

REFERENCE TO MICROFICHE ^VPPENDIX 

An appendix (appearing now m paper tormai to be 
reolaced later in microfiche tormat) torms part of ihis 
ippUcation. The appendix, which includes a source code 
listing reiatiae to an embodimeni of the invention, includes 
69 i frames on 8 microfiche. 

This patent document (including the microriche appendix) 
contains material that is subject to copynght protection. The 
copynght owner has no objection to the facsimile reproduc- 
tion by anyone of the patent document as il appears in the 
Patent and Trademark Office hlc or records, but otherwise 
reserves ail copyright rights whatsoever. 

BACKGROUND OF THE INVENTION 

This invention relates lo synchrumzing mcompAiible 
databases. 

Databases are collections of data entries which are 
ortjanized, stored, and manipulated in a manner specitied by 
appiicaiions known as database managers (hereinafter also 
referred to as "Applications"). The manner m wnich data- 
base entries are organized in a database is known as the data 
>iructure. There are generailv two tvpes or aatabase man- 
agers. First are general purpose database managers m which 
ihe user determines (usually ai the ouiset, but subject to 
future revisions) what the data structure is These Appiica- 
iions often have their own programming language and 
provide great Ilexibihty lu the user. Second are special 
purpose database managers that are specihcaily designed lo 
create and manage a database havmg a preset data .structure. 
Examples of these special purpose database managers arc 
various scheduling, diar>% and contact manager Apphcations 
for desktop and handheld computers. Database managers 
organize the information in a database into records, with 
each record made up of fields. Fields and records of a 
database may have many different characteristics dcpcndmg 
on the database manager's purpose and utility 

Databases can be said to be incompatible with one another 
when the data structure oC one is not the same as ihe data 
slruclure of another, even ihough some of the cunieni ol Ihe 
'dcofds is substautiaiiy the same. For example, one database 
may store names and addresses ui the followmg helds: 
FIRST_NAME, LAST_NAME, and ADDRESS. Another 
database may, however, store the same mformation with the 
following structure: NAME, STREET__NO., STREET_ 
NAME, CITY_STArE, and ZIR Although the content of 
the records is intended to contain the same kind of 
information, the organization of that intormation is com- 
pletely different. 

It is often the case that users of incompatible databases 
want to be able to synchronize the databases. For example, 
tn the context of scheduling and contact manager 
Applications, a person might use one Application on the 
desktop computer at work and another on his handheld 
computer or his laptop computer at home. It is desirable for 
many of these users to be able to synchronize the entries on 
one with entries on another. However, the incompatibility of 
the two databases creates many problems that need to be 
solved for successful synchromzatton. ihe U.S. patent and 
copending patent appkcation of the assignee hereof, Intel- 
liLink Corp., of Nashua, N.H. (U.S. Pat, No. 5,392390; U.S. 
application, Ser. No. 08/371,194, hied on Jan. 11, 1995, now 
U.S. Pat. No. 5,684,990, incorporated by reference herein) 
show two methods for synchronizing incompatible data- 



bases and solving some of the problems ansing from incom- 
palibilily or databases. However, other problems remam. 

One kind of incompaubilitv is wnen one database man- 
ager uses recumne records. Recurring records are single 
records which contain information which indicates that the 
records aciuaily represent multiple records sharing some 
common miormation. Manv scneduling Applications, for 
example, permit as a single record an even; which occurs 
regularly over a period of time, instances of such entries are 
biweekW committee meetings or weekly stall lunches. Other 
scheduling Applications do not use these types of records. A 
user has to create eniuvaient ciilries by creating a separate 
record for each instance of these recurring events. 

Various prot^iems anse when synchronising these types of 
records. Let us consider a situation when Appiicadon Auses 
recurnng records while Application B does not. A synchro- 
nizing application must be able to create multiple entries for 
B for eacn recurring entry in A. It also must be able to 
identify some of the records in database B as instances of 
recurring records in database A. Also, many Applications 
which allow recurring recoras also pernut revision and 
editing ot single instances of recurnng records without 
affecting the master recurrmg record. Moreover, single 
instances ot a recurring event in Application B may be 
changed or deleted The recurnng master may also be 
changed which has the effect of changmg ail instances. 
These changes make it harder to luentuy muitipie entnes in 
database B as instances ol a recurnng record m database A. 
Moreover, synchronization must take these changes into 
account when updating records ia one or the other database. 

SUMMARY OF THE INVENTION 

The invention provides a technique tor synchronizing 
databases m which different techniques arc used tor stonng 
a recurnng event. A database in which the recurnng event is, 
tor example, stored as a smgie recurnng record can be 
synchronized with a database m which the same recurnng 
event is stored as a senes of individual records. The indi- 
vidual records are processed to form a synthetic recurnng 
record represenung the set of individual records, and syn- 
chronization decisions are based on a comparison of the 
synthetic record to the recurnng record of the other database. 
Following synchronizauon, the synthetic record can be 
•'fanned" back mto the mdividuai records to update the 
database containing individual recoras, and the updated 
recurrmg record can be written back to the other database. 
In this way. the invenuon avoids the problems encountered 
with prior methods, in which synchronization resulted in a 
recurring record being iransiormed mto a series of mdi- 
viduai records. 

The invention features a computer implemented method 
of synchronizing at least a first and a second database^ 
wherein the manner of stonng a set of recurring instances 
differs between the first and second databases, and at least 
the first database uses a recurring record to store the set of 
recurring instances. A plurahty of instances in the second 
database are processed to generate a synthetic recurring 
record representing recurring instances in the second 
database, the synthetic recurnng record of the second dau- 
base is compared to a recurnng record of the first database, 
and synchronization is completed based on the outcome of 
the companson. 

Preferred embodiments of the invention may include one 
or more of the following teatures: Completmg synchroni- 
zation may include adding, modifying, or deletmg the syn- 
thetic recurnng record or the recuning record. Following 
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synchronization, the symtiedc recurring record mav be 
fanned back into a piuraiiiv ot single instances. The set or 
recurnng insiances may be siored m the second database a^ 
a piuraiitv of single instances. Fhe i>el ot" recurrme instances 
may be stored m the second database as a rccurnng record 
having a different record structure than the recurring record 
ot the ^irst database. A historv riJe mav be stored coniammg 
a record representative of the presence oJt a recurnng record 
or a synthetic recumng record in past synchronizations. 

The mveniiun may be impicmented in hardware ur 
soi\ware, or a combination of both. Preierably. the lechnique 
is iiiipieiucnted in computer prog,rams execiumg on pro- 
gramoiable computers that each laciude a processor, a 
storage medium readable by tfie processor (mcluding vna- 
tilc and non -volatile memory and/or storage elemenLsi, at 
least one mput device, and at least one output device. 
Program code is applied to data entered using the input 
device to pertbrm the tunctions described above and to 
generate output information The output intormaiion is 
applied to one or more output devices. 

Each program is preferably implemeniea in a high level 
procedural or object oriented programming language to 
communicate with a computer svstem. However, the pro- 
grams can be implemented m assembly or machine 
language, if desired. In any case, the language mav be a 
complied or interpreted language. 

Each such computer program is prctcrably stored on a 
storage medium or device (e.g., HUM or magnetic diskette,) 
that IS readable by a general or special purpose program- 
mable computer for configuring and operating the computer 
when the storage medium or device is read by the computer 
to perform the procedures descnbed m this document. The 
system may also be considered to be impiememed as a 
computer-readable storage medium, configured with a com- 
puter program, where the storage medium so configured 
causes a computer to operate in a specific and predefined 
manner. 

Other features and advantages of the invention wiii 
become apparent from the following dcscnption of preferred 
embodiments, including the drawings, and from the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic drawing of the vanous modules 
consututing the preferred embodiment. 

FIG. 2 is a representation of the Workspace data array. 

FIG. 3 is the pseudocode for the Translation Engme 
Control Module. 

FIG. 4 shows the relationship between 

FIGS. 4A and 4B; FIGS. 4A and 4B, in combination, are 
the pseudocode for generating the parameter Table. 

FIG. 5 shows the relationship between 

FIGS. 5A and 5B; FIGS. 5Aand 5B. in combinauon, are 
the pseudocode for fanning a recurring recora, 

FIG. 6 is the pseudocode for the Synchronizer loadmg the 
History File. 

FIG. 7 Is the pseudocode for matching key fields (Key_ 
Field_Match). 

FIG. 8 is the pseudocode for loading records of 
B_Database into Workspace. 

FIG. 9 is the pseudocode for A Sanitization ot 
B Database records in Workspace. 

FIG- 10 is the Pseudocode for a specific example of d rule 
of data value used for saniii^^alton. 

FIG. U is the pseudocode for onentation analysis. 



FIG. 12 is the pseudocode for Conliici .Ajialvsis And 
Resolution (CAAR). 

FIG. 13 is the pseudocode tor analyzing unique ID 
bearing Fanned Instance Groups ^FIGs). 

FIG. 14 IS the pseuaocnde {or expanding CIGs created 
trora unique ID beanng records. 

FIG. 15 IS the pseudocode tor finding weak matches tor 
a record. 

FIG. 16 shows the reiationship between FIGS. 16A and 
L6B; 

FIGS. 16A and 16B, in combination, are tne nseuaocode 
for findine matches between recurnn^ items and Qon_ 
unique ID beanng instances, 

FIG, 17 is the pseudocode for completing Same Key 
Group (SKG) analysis. 

FIG. 18 is the pseudocode for setting the Maximum^ 
C]G_Si2e for every GIG analyzed m FIG 17. 

FIG. 19 shows the reiationship he twee n 

FIGS. 19Aand i9B; FIGS. 19Aand i9B, in combmation, 
are the pseudocode for setting CIG_Types. 

FIG. 20 Ls the User Interface for conrlict resolution when 
■lie Notify option ls seiected. 

FIG. 21 is the pseudocode tor merging exclusion lists. 

FIG. 22 is a look up tanie used by the runction in FIG. 21. 

FIG. 23 is a look up tabic used by the runction in FIG. 21. 

FIG. 24 is a look up taole used by the function in FIG. 21. 

FIG. 25 shows the relationship between FIGS. 25A and 
25B; 

FIGS. 25A and 25B, in combination, are a pseudocode for 
unloading records from Workspace to a non-rebuild-ail 
database. 

FIG. 26 shows the relationship be^veen FIGS. 26 A, 26B, 
26Q and 26D; 

FIGS. 26 A, 26B, 260. and 26D in combination, illustrate 
the look up table for determining loading outcome results. 

FIG. 27 shows the relationship between FIGS. 27A and 
27C; 

FIGS. 27A and 27B, in comomation, are tne pseudocode 
for fannmg recumng records of A-Database lor unloading. 

FIG. 28 is the pseudocode for unloading the Historv File. 

FIG. 29 is a table showing cases in which Recurring 
Masters are fanned into own database. 

FTG. 30 is the pseudocode for loading records by a fa.st 
synchronization Translator. 

FIG. 31 shows the relationship between FIGS. 31A and 
31B; 

FIGS. 31 A and 31 B, in combination, arc the pscudococ 
for loading records by a fast synchronization Translator. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

FIG. 1 shows the relationship between the various mod- 
ules of the preferred embodiment. Translation Engine 1 
comprises Control Module 2 and Parameters Tabic Genera- 
tor 3. Control Module 2 is responsible for controlling ihc 
synchronizing process by instructmg vanous modules to 
perform specitic tasks on the records of the two databases 
being synchronized. The steps taken by this module are 
demonstrated in FIG. 3. The Parameters Table Generator 3 
IS responsible for creating a Parameter_Table 4 which is 
used by all other modules for synchronizing the databases. 
Details of the Parameter_TabIe are descnbed in more detail 
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below. Tiie Synchroni7,er \5 has primarv responsibility tnr 
carrying out the core synchronizing iunciions. U js a taolc- 
dnven code which is capable of synchronizing vanous types 
of databases wnose charactenstics are provided m ihe 
Parameter _Tab[e 4. The Synchronizer creates and uses the 
Workspace 16, which is a lemporary daia array used dunn^ 
the synchroni/ation process. 

A Translator 5 (A„Transiator) is assigned to the 
A„daiabase 13 and another Translator 9 {B„Tran^lator^ to 
the BJatabase 14. Each of the database Translators 5 and 
9 comprises three modules: Reader modules 6 and 10 
(A„Reader and B_ReaderK which read the dala from the 
databases 13 and 14; Unloader modules 8 and 12 
(A_Unloader and B__Un loader), which analyze and unload 
records from the Workspace into the databases 13 and 14, 
and Sanitizing modviles 7 and 11 (A_Samtizer and 
B^Sanitizer), which analyze the records of the oiher data- 
base loaded into tne Workspace and modify them according 
to rules of data value of iLs own database. In the preferred 
embodiment, the modules of the A_Transiator 5 are 
designed spccmcally for interacting with the A^database 13 
and the A__AppiicaUon 17. Their design is specifically based 
on the record and field structures and the rules of data value 
imposed on them by the A^Application. the Application 
Program interface (API) requirements and limitations oi the 

A^j^pplication and other characterisucs of A Database 

and A„ Application. The same is true or the moauics oi 
B Translator 9. These Translators arc not able to interact 
with any other databases or Applicaiions, They arc only 
aware of the characteristics of the database and the Appli- 
cation for which they have been designed, llierefore, in die 
prefeaed embodiment, when the user chooses two Appkca- 
Uons for synchronization, the Translation Engine chooses 
the two Translators which are able to interact with those 
Applications. In an alternate embodiment, the translator can 
be designed as a lable-dnven code, where a general Trans- 
lator is able to interact with a vanety of Applications and 
databases based on the parameters supplied by the Transla- 
tioQ Engine 1. 

Referring to FIGS. 1, 2 and 3, the synchronization process 
is as toliows. The Parameter Tabic 4 is generated by the 
Parameter iable Generator 3. llie Synchronizer 15 then 
creates the Workspace 16 data array and loads the History 
File 19 into the Workspace 16. l"he B Reader module 11 at 
the B_rranslator reads the H_database records and sends 
them to the Synchronizer tor wnting mto the Workspace. 
Following the loading or B__Database records, the 
A_jSaniti2er module 8 of the A_Transiator 5 sanitizes the 
B_Records in the Workspace. The A_Reader module 7 of 
the A_Traiislator 5 then reads the A_Database records and 
sends them to the Synchronizer 16 for writing into the 
Workspace. The B_Sanitizer module 12 of the 
B„Transiator 9 then sanitizes the A_Records in the Work- 
space. The Synchronizer then performs the Conflict Analysis 
and Resolution (CAAR) on the records in Workspace. At the 
end of this analysis the user is asked whether he/she would 
like to proceed with updating the A_ and B_databases. if 
so, the B_Unioader module of ihe B_Transiator unloads 
the appropriate records into the B_database. The 
A__Unloader module 6 then performs the same task for the 
A__Database. Finally, the Syncbromzer creates a new His- 
tory FHe 19. 

FIG. 3 is the pseudocode for the preferred embodiment of 
the Control Module 2 of the Translation Engine 1. Control 
Module 2 first instructs the Parameter Table Generator 3 of 
the Translatioa Engine 1 to create the Parameter_Tabie 
(Step 100). FIGS. 4A and 4B are the pseudocode for die 



pretenred embodiment of the Parameter Tabic Generator 
module 3. The user is first asked to choose whether to ilsc a 
previously chosen and stored set of preferences or lo enter 
a new set of preferences {Step I50> Steps i51-l 65 show the 
steps in which the user inputs his/her new preferences. In 
.step 152, the user chooses whether to pcrfomi a synchroni- 
zation from scratch or an mcremenial synchronization. In a 
^synchronizauon from scratch, synchronization is pertorraed 
as if this was the first tunc the two databases were Dcmg 
synchronized. In an incremental synchronization, ihc His- 
tory Flic from the previous file is used to assist with 
:>ynchronization. ihe user wiii iikeiy choose incremental 
synchronization it' there has been a pnor synchroaizauon, 
but the user may choose to synchronize from scratch where 
the user would hke to start with a dean slate {perhaps due 
to signiiicant change in the nature of the data m the 
databases). The user then selects the two Applications and 
related databases (A„Database and BJatabase) to be 
synchronized (step 153). The user then chooses (step 154) 
whether the Synchronizer should use the default field map- 
ping for those two databases during synchronization or the 
user will modify the field mapping. Field maopms; is ^en- 
^raily descnbed in U.S. Pat No. 5,392.390 finconDoratsa by 
referenced. In accordance with the user's preterences, the 
Parameter Table Generator then stores the appropriate 
/-w_Database to B_Database nelds raao (A-*B„MaD) and 
3_Database to A_Database tields map ^B-^A_iVlap) in the 
?arameter_Table (Steps 155-158 and 159-163, 
accordingly). 

li in step 150 the user selected to use previously chosen 
and stored set of preferences (steps 166-171), those prefer- 
ences are loaded and stored m the Parameter„iable (steps 
169-170) 

In case of dale bearing records such as appoinimenis and 
ToDo lisls. the user enters the date range for which the user 
wants the records to be synchronized (step 172) The pre- 
ferred embodiment allows the user to use rclalive date 
ranges (Automaiic_Date_Raaa,e) (substsps 171 (a) and 
(/?)). For example, the user can select the date range to be ?iO 
days into the past from today's date and 60 days into the 
future from today's dale. The Parameter Table Generator 3 
then calculates and stores m the Paramcier„Tabie the Start_ 
Current_Date_Rangc and Ciid„Current_Datc_Range 
values, the two variables indicating the starting pomt and the 
ending point of the date range tor the current synchroniza- 
tion session (step 173-174). 

In steps 174 and 175, various parameiers identifying the 
characteristics of the A_Database and Appiication and 
B_Database and Application are loaded from a database 
^uot shown) holding such data for different Appiicatioas. 
These are in turn stored in the Paramcier_Table, One of the 
sets of parameters loaded and stored in the Parameter_Tah!e 
is the Fic]d_T,ist for the two databases. The Field__f ,ist_A 
and Ficld_T.ist_B contain the foHovinng information about 
each field in the data structure of the two databases; 

1. Field name. 

2. Field Type. 

3. Field Limitations. 

4. No_Reconci1e Flag. 

6. Key_Field Flag, 

7. Mapped_Fieid Flag. 

Field name is the name given to the field which the Trans- 
lator for this Application uses. This name may also be the 
name used by the Application. Field Type identifies to the 
S>Ticbromzer 15 the nature of the data in a Held, e.g., Data, 
Time, Boolean, Text, Number, or Binary. The Field Name 
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does not supply this informatinn to the Synchmmzer. Field 
Limitations identifies the vanous limitations the database 
manager imposes on the contents of a tie Id. These limita- 
tions include: maximum length of text tields, whether the 
text field must be in upper-case, range ol permissible values 
(for example, in ToDo records pnonty tie Id, the range or 
perniissibie values may be limited trom i to 4), and whether 
a smgie line or muhiplc line tieid. 

No_Rcconciic hag mdicatcs whether a held is a 
No Reconcile held, mcamng that a will not be usca to 
match records nor will il be synchronized although it will be 
mapped and possibly used in syncnromzation. Almost ail 
holds wiU not be designated as No Reconcile, However, 
sometimes it is necessary to do so. Key bield flag indicates 
that a held should be considered as a key held by the 
Synchronizer 15. 

Key fields are used by the Synchronizer in vanous stages 
of synchronization as wiii be discussed in detail below. The 
decision of identifying certain he Ids as key is based on 
examining the vanous Applications to be synchronized, their 
data structure, and the purpose for which the database is 
used. Such exammation reveals which fields would best 
funcuon as key helds for syncnromzation. For example, for 
an address book database, me lastnarae, arstname. and 
company name field may oe cnosen as key fields. For 
Appointments, the date field and the descnption held may be 
chosen as key fields. 

Mapped_Field flag indicates whether a field is manped at 
all. The Synchronizer uses this flag to determine whether it 
should use the A->B_Map or B-^-A^Map to map this field. 
Unlike a No_Reconcile field, an immapped field will not be 
earned along through the synchronization. 

Another set of parameters in the Parameter_Table iden- 
tify the Translator Modules 13, 14 for the two Applications 
which the user has selected. Because each Application is 
assigned its own Translator, it is necessary to identify to the 
Command Module and the Synchronizer which Translators 
should be used. 

In slep 102 of FIG. 1, (he Translation Engine msirucis the 
Synchronizer to load the History File. History File is the file 
which was saved at the end of last syochromzauon. It 
contains the history of the previous synchronization wnich is 
necessar)^ for use with the current synchronization in ca.se of 
hicrementai Synchronization. Records from the 

A_ Database and B Database are analy7ed against the 

records of the hi.story file to determine the changes, 
additions, and deletions m each of two databases since last 
synchronization and whether additions, deletions, or updates 
need to be done to the records of the databases. Referring to 
FIGS. 5Aand 5B, in steps 200-201, the SynchrDnizcr finds 
the appropriate History file to be loaded. If 
Synchronization from Scratch hag is set, the History File 
is deleted (step 203). If no History Fiic is found, the 
synchronization will proceed as if it was a synchronization 
from scratch (step 204). If the Field Lists stored in the 
History File are not the same as the current Field Lists m the 
Parameter^lable, or the mappmg mformation is not the 
same, the synchronization will proceed as synchronization 
from scratch because the differences mdicate that the His- 
tory File records will not properly matcn the database 
records (steps 206-209). 

In step 210, the Synchronizer uses the Field_List for 
database B to create the Workspace 16. It is a large record 
array which the Synchronizer uses during synchronization. 
Referrmg to FIG. 2, Workspace 16 consist of two sections. 
First, the Synchronizer uses the Field List for the 
B_Database to make a record array 21 which has all the 
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v.iiaractens[ics of the R_Database record .struciurc. in 
iddition. m each rccora m the Workspace, certain mtcrnal 
Meids are added. Oae tie id is ^subtype containing Ongm 
Tags. Two ottier fields, caiied Rep_Basic ana Rep_Exci, 
are included for ail Appoimment and To Do Sections. The 
Rep_Biisic litiid gives a lull descnpiion oi ihe recurrence 
pattern or a recurnng record, [l includes the following 
parameters: 

1. Basic_Repcat_Typc 

2. Frequency 

3. SlupDale 

4. other parameters 

5. Rep Exci 

Basic Repeat lype contains the vanable which indi- 
cates whether the recurnng record is a daily, weekly, 
monthly (same date each month), monthly by position (e.g., 
3rd Friday of each momh), yearly (e.g., July 4th each year), 
yearly by Position (e.g., 3rd Friday of September each year), 
quarterly, etc. Tnis vanable is set to No_Repeat lor non- 
recumng records. 

Frequency indicates whether the pattern is, for example, 
for everv week, every other week. etc. StartDate and Stop- 
Date show the first date and last date m the pattern. Some 
ether parameters m the Rep_Basic mciude, for example, a 
list of days to be mciuded for the pattern fe g. 1 plan to tiold 
a weekly staff meetmg everv Thursday startmg Nov. 15, 
1997.) 

Rep_Excl is the exclusion list. It is a list of dates which 
at some point belonged to the recurnng record, but have 
smce been deleted or modified and no longer are an event 
represented by the recurring record. 

Since some databases do not provide for recurnng types 
of records, the synchro mzadon process sometimes musi 
create single records for each of the instances of a recurnng 
record for those databases. For example, for a recurring 
lunch every Thursday, the synchronizadon must produce a 
single record for each Thursday in such a database. This is 
accomplished by the process of fanning which uses Rep_ 
Bassit;. Each of those instances is caiied a fanned instance. 
FIG. 6 sets out the preferred embodiment of the process of 
fanning a record. 

Fanning of recurring records also takes into account 
another .set of cnnsideranons regarding date range limita- 
tious and usehilness of instances to liie user. 

FiTst, fanning is limited to the applicable date range. 
Second, the number of fanned iastanccs is limited. When 
synchronizing Databases A and B, the preterred embodiment 
permits different sets of limits on fanned instances to be 
established for each Database. This, for example, assists 
with managing storage capacity of a memory-constrained 
handheld device when being synchronized with a database 
on a desktop PC. 

If the current Date Range is large enough to accommodate 
more than the maximum number of instances which might 
be generated, those instances wiU be chosen which are likely 
to be most useful to the user, in the preferred embodiment. 
It is assumed that future instances are always more useful 
than past mstances, that near future instances are more 
useful than distant future mstances, and that recent past 
instances are more useful than distant past instances. 
Therefore, based on these assumptions, a fanning date range 
is calculated (FIG. 6, step 236). 

Referring to FIG. 2, in the second step of creating the 
Workspace, the Synchronizer establishes an Extended Index 
Array 20 which has an index entry associated with each 
entry in the record array. Each index contains the foUowir^ 
variables: 



I Ncxt_[n_CIG 
2- Next Jn_SKG 

3. Next_In_FIG 

4. Key_^leid_Hash 

5. A_Unique_ID_Hash 

6. B_Unique_iD__Hash 

7 Non_Kev_F]eici_Hish 

3. Non_Date_IIash 

9 ExcIui>ion_LL>l_Hash 

10. Start_Date&TLme 

11. Hnd_Date&Ume 

12. VanoiLS bit flags 

Mext_ln_CIG is a iankage word, pointing to next mem- 
ber of the same Carrespnnding Item Group (CIG) A CIG is 
a group of records, one from each database and the History 
File, if applicable, which represent the same entry- m each of 
the databases and the Histnr>' File. There may ne one, two 
or three records in a CIG. Next_in_SKG is a hnkage word, 
pointing to next member of the Same Key Fields Group 
(SKG). An SKG is a group of records having the same key 

fields. Next _Iq flG is a linkage word, poinimg to the next 

member of the Fanned Instances Group [flG). A FIG is the 
group ot fanned mstances which correspond to a single 
recurnng record. 

Key_Ficld_IIash is hash ot all KeyJields. A_unique_ 
ID_IIash is hash of unique ID. if any, assigned by 
A_Databasc. B_uniquc_ID_Hash is hash ot unique ID, if 
any/ assigned by B Database. Non Key Field Hash is 
hash ot all Non-Key Match Field, a Match Field being any 
mapped field which is not flagged as No Rcconcdc. Non 
Date Hash is bash of all Non-Date Non-Key Match Fields, 
Hxcfusion_List_Hash is hash of recurnng record's exclu- 
sion list. 

Start Date&'lime and End Date&'lime are used for 
Appointment and'lbOo type record only, mdicatmg the start 
and end date and time of the record. Fhcy arc used to speed 
up comparing functions throughout the syncaromzatioa. 
Hash values are also used to speed up the process of 
companson. The preferred embodiment uses integer nashes. 
Hash value computaUon takes into account certam rules of 
aata value for fields, as will be described m more detail 
below. 

In the preferred embodiment, the record array 21 is stored 
on magnetic disk of a computer whereas the Extended Index 
20 IS held resident m memory. The Extended Indexes have 
record pointer fields which point to each of the records on 
the disk file. 

The Control Module 2 now instructs the syncrironizer to 
load the History File into the Workspace (FIG. 3. step 102). 
Referring to FIG. 6, the synchronizer loads the records 
beginning in first available spot m the Workspace (step 211). 
The Synchronizer then performs an analysis on each of the 
records and resets some of the values in the records (steps 
212-228). The records are also checked against the current 
date range and those failing outside of it are marked appro- 
priately for Fast synchronization function, which will be 
descnbed below. In case of recurring records, if any of the 
instances is within the current date range, then the recumns 
record itself will be considered withm the current date range 
(steps 217-227). 

The synchromzer then builds SKGs by finding for each 
history record one record which has matctimg key fields and 
by placing that record in the SKG of the history record (step 
215-216). Referring to FIG. 7» steps 250-258 descnbe the 
Kev_Field_Match function used for matching records for 
SKG. 
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Whea comparing iwo records or \wu lie Ids, in ihc orc- 
terred einhodimenu (he COMPARE function is used "Hie 
COMPARE ftjuctioa is luteliigeut compafLSoa logic, which 
Uikes into i^ccolldl same oi.' ihe difftrences belween the rules 
of data value imposed by fbe A_Appiicatioii and the 
B_Appiicariou on rheir rijspective dntabases. Same 
examples are as t'oUows Tlie COMPARE hinciion is insen- 
sitive to upper arid lower case letters if case insensiTive field 
attribute is present Because some Applications require 
entries to be in all capital letter, the COMPARE function 
iguores the differences iietween upper and lowercase letters. 
The COMPARE function takes into account any text length 
liniiiations. For example, when comparing "App" in the 
A_Database and "Apple ' in the B__Database, the COM- 
PARE function takes into account that this field is limited to 
oniy 3 characters in the A„Database. li also takes into 
account limits on numerical value. For example, priority 
fields in the A_ Application may be limited to only values up 
to 3, whereas la the B„Appiicacioa there may not be any 
limitation. The COMPARE fti action would treat all values in 
B_records above 3 as 3. 

The COMPARE function may ignore vanous codes such 
ni end of line cnaractcrs. It may sinp punctuation trom some 
fields such as telephone numoers ana trailing wnite space 
from text fields (i.e "Hello " is treated as •Hello"). It also 
considers tie Id mapping. For example, if the only line that is 
mapped by the A^D__Map is the first line of a field, then 
only that line is compared. When comparmg appointment 
fields, because diticrcnt databases handle alarm date and 
time differently when Alarmfiag is lalsc, the COMPARE 
function treats them as equal even though the values m them 
arc not the same. It skips Alarm Date and Time, it the Alarm 
Flag is Ealse. It also ignores exclusion hits when comparmg 
rccumng records. 

In aa alternate embodiment, the COMPARE hinction may 
take into account more complicated rules tor data value of 
the two Apphcations. such as the rules tor data value 
imposed by Microsoft Schedule-t-, described above Such a 
COMPARE function may be implemented as a table dnven 
code, the table containing the rules imposed by the 
A_Appiication and die B_Application Because the COM- 
PARE function nas a specific comparison logic and takes 
into account a numt^er or rules, t£ie hashing logic must also 
follow the same rules It shouia be noted that the COMPARE 
function IS used throughout the preferred embodiment for 
field compansons. 

Sow that the History File is loaded into the Workspace, 
the Control Nodule 2 instructs the B_Transiator 13 to load 
the B_Database records (FIG. 3, step 103). Referring to 
FIG. S, steps 300-308. the B„Reader module li of the 
B__Transiator 13 loads each B_record which has the right 
Origin Tag, which will be explained m more detail below. 

The record must also be within the loading date range, 
which is a concatenauon of the previous and current date 
ranges. The B_Translator sends these records to the Syn- 
chromzer whicfi in turn stores them in the Workspace. When 
synchronizing with a date range limitation, all records which 
fall within either the previous or the current date ranges are 
loaded. The current date range is used durmg unloading lo 
limit the unloading of the records to oniy those records 
which fall within the database's current date range. In an 
alternate embodiment of the invention, each database or 
Application can have its own date range for each synchro- 
ni2aiion. 

Most Applications or databases permit record-specific and 
field-specific updates to a Database. But some Applications 
or databases do not. Instead the Translator for these Appii- 
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cation must re-create the waole database trom scratch vvnen 
unioading a the ena ot synchronization. These aatabases are 
identified as Rebuiid_All daiaoases. To accommodate this 
requirement all records from suca a database must be loaded 
into the Workspace, so that they can later be used lo rebuild 
the whole database. These databases records, which would 
ctherv^'ise have been hltered out by tne date range or the 
wrong ongin tag hllers, are instead markea with special ilag 
bits as Out_Of_Range or Wrong„Section_Subtype. These 
records will be ignored during the synchronization process 
but will be written back unmodiried into the database trom 
which they came by the responsiole Unioader module 6. 10. 

Control Module 2 next instructs the A_Translator 5 to 
sanitize the B-recoras. Referring to FIG. 9, steps 350-361, 
the A_Saaitizer module 8 ot the A_Translator 5 is designed 
to take a record having the form ot an A_Record and make 
it conform to the specific rules of data value imposed by the 
A_Appiication on records of the A„Database. A__Sanitizer 
is noi aware which database s field and records it is making 
to conform to us own Application s format, h is only aware 
of the A„Appiication*s field and record structure or data 
siruciure. Therefore, when it rsouests a neid from the 
^anitizer using the A__Database Held name, it is asking for 
heids having tne A._Database aata structure The 
Synchronizer, m steps 375-387, there lore maps eacn recora 
according to the B— >A_Map. in turn, when the Synchro- 
nizer receives the fields &om tne A_SANITIZER, it waits 
until it assembles a whole record (by keeping the values in 
a cache) and then maps the recora back mto the B format 
using the A-»B_Map. 

How a record or a field is sanitized m step 354 and 357 
depends on the rules of data value imposed by the 
A_App lie alio n. For example, ail of the logic of intelligent 
comparison in the COMPARE function described above can 
be implemented by sanitization. However, sanilization is 
best suited for more complex or umque ty^pes of database 
rules for data value. For example, consider the Schedule+ 
rules regarding alarm bearing Tasks records described 
above. FIG. 10 shows a samuzation meihod for making 
records of incompatible databases conform to the require- 
ments of Schedule+ Without sanitization, when a Tasks 
record of a Schedule database is compared to iis corre- 
sponding record m another database, the Tasks record may 
be updated m fields which should be blank according to the 
Schedule+ rules of data value. Such an update may possibly 
affect the proper operation of Schedule -i- after syncnromza- 
tion. 

Referring to FIG. 11, following sanitization of all 
B„Records into the Workspace, the Synchronizer sets the 
values for the Extended Index of each record based on the 
record's values (steps 451-459). Also if the records in the 
B_Datafaase bear a unique ID, and matches tor those unique 
IDs are found in the H_Records in the Workspace, the two 
records are joined in a CIG because they represent the same 
record in both History File and B_Database (step 462). The 
record is also joined to an SKG it may belong to (step 464). 
The loading of B_Records is now complete. 

The Control Module 2 of the Translation Engine 3 now 
instructs the A_Translator 5 to load the records from the 
A_Database (step 105). The loading process for the 
A__Records is the same as the loading process for the 
B_Database, except for some differences arising trom the 
fact that records in the Workspace are stored according to the 
B_Database data structure. Therefore, as the synchromzer 
15 receives each A_record from the A_Reader module 7 of 
the A_Translator 5. the Synchronizer maps that record using 
the A-'-B^Map before writing the record into the next 
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available spoi m the Workspace. Since ihe A__recoras are 
mapped mio ttie B_Recora tbrmai, when tne B_Samti2eris 
instructed by the Control Module 2 to beeiQ samiizms tnose 
records and starts asking tor mem irom tne synchronizer, 
tney already have the B__Database tormai. Therefore, the 
^yachronizer 15 does not need to map them betore sending 
nem to the B_Saniiizer moauie 12 oi" the B^Transiator 19. 
For the same reason, there is no need for them to be mapped 
once they are sent back by the B_Sanitizer after havmg been 
sanitized. Once all the records are loaded, the records mil 
undergo the same onentation analysis mat the B_Records 
underwent (FIG. 11). 

At this point, all records are loaded into the Workspace. 
SKGs are complete smce every record at the time of loading 
IS connected to the appropnate SKG. CIGs now contain all 
records that could be matched based on unique IDs. At this 
pomt, the records in the Workspace will be analyzed accord- 
ing to Conflict Analysis and Resolution ("CAAR'*) which is 
set out in FIG. 12 and m more detail m FIGS. 13-18 and 
corresponding detailed description. 

First, m step 500, ID beanng fanned instances in the 
History File records are matched to the tanned instances in 
the ID beanng database trom which ihey came. The records 
trom the database which have remained unchanged are 
formed into a new FIG. A new Syntnetic Master is created 
based on those records and joined to them. The records 
which have been changed or deleted since last sync&roni- 
zation are set free as single records. They also result in a new 
exclusion list being created based on an old exclusion list 
and these new smgie records. 

Second, in step 501, matcnes are sought for the ID based 
CIGs which are the only CIGs so far created in order to 
increase the membership of those CIGs. Preferably an exact 
all fields match is sought between current members of a CIG 
and a new one. Failii^ that, a weaker match is sought. 

Third, in step 502, masier/msiances match is sought 
between recurring records and non-unique ID bearing 
instances by trying to find the largest group of instances 
which match certain values in the Recurring Master. 

Fourth, in step 503, the items remaining in the SKGs are 
matched up based on either exact all field match or master/ 
instance match, or a weaker match. 

Fifth, in step 501, the appropriate CIG_T>pes are set for 
all the CIGs. CIG_Types will determine what the outcome 
of unloading the records will be. 

Referrmg to FIG. 13, first step in CAAR is analyzing 
umque ID beanng Fanned Instance Groups. This analysis 
attempts to optimize using unique IDs assigned by databases 
in analyzing fanned instances of recurring records. 

The analysis is performed for all Recurnng Masters (i.e. 
all recurring records) which have ID-bearing fanned 
instances (or FIG records) in the H_File (step 550), All FIG 
records in the History File associated with a Recurring 
Master are analyzed (steps 551-559). They are ail removed 
from the SKG. If a FIG record is a singleton CIG, it means 
that it was deleted from the database since the previous 
synchroQizaiion. Therefore, it is added to the New„ 
Exclusion_List (step 553). If a FIG record is a doubleton 
and is an exact match, it means that the record was not 
modified since the previous synchronizauon, in this case, the 
record from the database is also removed from SKG (step 
555). If a FIG record is a doubleton but is not an exact match 
for its counterpart m the database, it means mat the record 
was changed m the database. The History File record is 
treated as a deletion and therefore added to the Mew__ 
Exclusion_List. The modified record in the database, which 
does not match the recurring record any longer, is treated as 
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a tree standing record un-associaied wnti the Recurring 
Master (step 557) 

Upon anaivsis o( all FIG records, a new record, the 
Synthetic Master, is created and lomed m a CIG wun the 
Recurring Master (step 231-236) The Symneuc Master has 
ibe same charactenstics as the Recumnc Master, except tnat 
it has a new exclusion list which is a merger ot the 
Mew__E.^clusion_Ust and the Exclusion _List of the Recur- 
ang Master (step 563) Also a new FIG is created between 
the Synihetxc Master and the CIG-maies or all FIG records 
from the History File (step 565), 

In steps 567-569, the Synchronizer checks to see it there 
are some instances ot the Recurnng Master wmch fail witmn 
the previous synchronization s date range but fail outside of 
the current synchronization's date range. If so, the Fan_ 
Out_Creep iiag is set. indicating that the date range has 
moved in such a way as to require the record to he fanned 
for the database before unloading the record. The Fan„ 
Out_Creep hag is an increase m the value m the Non_ 
Key__Field Hash ot the Recurnng Master In this way, the 
Recurring Master during the unloading or the records will 
appear as having been updated since the last svuchromzation 
and theretore wiU be fanned tor the current aate ranee. 

In step 570, all the FIG records analyzed or created in this 
analysis are marked as Dependent _FIGs. This results in 
these records being ignored m future analysis except when 
the recurring records to which they are attached are beina 
analyzed. 

At die end of the above analysis, ail the records having a 
unique ID assigned by their databases have been matched 
based on their unique ID. From this point onward, the 
records which do not have umque IDs must be matched to 
other records based on their field values, in the preferred 
embodiment, there are two caiegones of field value matches: 
strong matches and weak matches. A strong match between 
two records that have matching key fields is when non-key 
fields of the two records match or it is a Recurring Master 
and a fanned instance match (FIG. 14, steps 606-610). 
Referring to FIG. 15, a weak match between two records that 
have maichmg key fields is when the following are true: 
each of the two records are from dilferent origins, because 
two records from the same source should not De m a CIG 
(e.g., A„Database and Hisiory File); each is not a weaK 
match for another record because there is no reason to oreter 
one weak match over another; each is not a Dependent _FIG 
since these records do not have an independant existence 
from their recurnng masters; both records are either recur- 
nng or non-recurrmg since a recurring and a nonrecumng 
should not be matched except if one is an instance of the 
other in which case a is a strong match; and, in case of 
noD-recurring, they have matching Key_Daie_Field which 
is the same as the Start_Date in the preterred embodiment 
because items on the same dale are more likely to be 
modified versions of one another. 

Referring to FIG. 14, these two types of matching are used 
to match records to existing CIGs for History File records 
which have been created based on matching unique IDs. 
Only doubieton CIGs are looked at, because singleton CIGs 
are handled in step 504 of FIG. 12 and tripleton CIGs are 
complete (steps 601-604). If a strong match is found, then 
if the record was a weak match in another CIG, it is removed 
from that CIG, and new weak niatch is found for that CIG 
(612-614). While weak matches are left in SKGs in case 
they will find a strong match, strong matches are removed 
from their SKGs (step 614). If a strong match is not found, 
then a weak match is sought (steps 617-^20). All records in 
the CIG are removed from SKG if no weak match is found, 
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because tbis means that there is no possibiUtv ot even a weak 
match for this record (siep 619) 

The next step in CAAR is tindmg non-unique ID beanng 
instances for recurnnc items (FIG. 12. step 5031 Rel'erring 
to FIGS. 16Aand 16B, this analysis takes place only if the 
database trom which instances matching a recumng record 
are sought does not pro viae unique ID or if we are synchro- 
nizing from scratch (steps 65(^653) The goal of ihis 
analysis is to find matching instances for each Recurring 
Master from a different source than the Recurnng Master 
This analysis counts the number of records m SKG of the 
Recurring Master which have matching Non_Date_Hash 
value (steps 665-669). The group of matchmg SKG records 
having the same non_Date_Hash value and having the 
highest number of members (if the number of members 
exceeds 30% of unexcluded instances) is then formed into a 
Homogeneous_Instances__Group (steps 670-672). A Syn- 
thetic Master is created using the Rep„Basic of the Recur- 
ring Master and using the values from the homogeneous 
instances group. An Exclusion list is created based on the 
items belongmg to the recurrence pattern but missing from 
the Homogeneous _Instances_Group. The Synthetic Master 
iS added lo the CIG ot the Recumng Master (steps 
673-678). A new FIG for the Synthetic Master is then 
created usmg the Homogeneous^Instances „Group (step 
679). These records are removed trom any CIGs to which 
they belonged as weak matches and new weak matches are 
sought for those CIGs (steps 680-684). Since the records in 
Horaogeneous_lnstances_Group have now been matcaed 
to a recumng record, they are marked as Dependent_FIGs 
(step 683). The Recurring Master s CIG is then marked with 
Fan_Out__Creep flag, if necessary (step 685). 

The next step in CAAR is completing analysis of records 
in SKGs (HG. 12, step 504). Referrmg to' FIG. 17, this 
analysis attempts to increase the population of CIGs up to a 
maximum by finding key field based matches with records 
from a source different from those of the CIG records. This 
analysis is performed by analyzing ail the records in the 
SKGs except for the singleton SKGs (steps 703 and 712). 
The first thing is to remove any members that have already 
been marked as WEAK matches attached to ID-based 
doubleton CIGs. Those are left in the SKG up to this pomt 
to allow tor the possibility that a STRONG match would be 
found instead. But that is not possible any longer (steps 
713-715). Once the weak matches have been removed, ail 
remaining SKG members belong to smgleton CIGs. Any 
non-smgieton CIGs which are lormed from here on wiU be 
purely key field based. 

Throughout the remaining SKG Analysis we are careful 
not to seek H_Record-A_Record or H_Record-B_Record 
matches for unique ID-bearmg Source, since that would 
violate the exclusively ID-based matchmg scheme that 
applies in such cases. Note however that an A_Record-B_ 
Record match is acceptable even if both A_Database and 
B_Database are unique ID -bearing databases. 

Given thai Key Field should not be performed where ID 
based matches are available (or otherwise there may be 
matches between records with differing IDs), there are limits 
to how big CIGs can get at this point. If both A and 
B_Databases are unique ID-bearmg, any remaining 
H_Record must remain in Singleton CIGs, because they are 
prohibited from forming key fields based matches with items 
from either databases. Such H_Records are simply removed 
from the SKG when they are encountered. If just one of the 
two databases being synchronized is unique ID-bearing then 
the maximum population that any CIG can now atiam is 2 
(FIG. 18, steps 750-751), If neither database is unique ID 



15 

bearinc then the CIG_Max_SLze is ihree. For ever\' CIG 
which is analyzed in FIG. 17, the ClG_Max_Size is sei 
according lo this logic. When a CIG reaches its maximum 
possible popidation ail of its members are removed trora the 
appropnate SKG. 

First, strong matches for the H- records are searched for, 
before trying to find A-B matcnes. It both Databases are 
non-unique ID -bearing then two strong matches for eacn 
H_Record^ an H-A and an H-B matcn, are sought (steps 
715-720). If finding a strong match results m reachmg the 
ClG_Max_Size, ail members or the CIG are removed from 
the SKG (step 721). 

When maximum CIG population is 3, weak matches are 
sought for strong matching CIG doubleton in order to build 
triplet CIGs. The first weaklv matching SKG member is 
added to the CIG (steps 722-728). Whether or not a weak 
match is found for any of the doubleton CIGs, its members 
are removed from the SKG (step 726). As there are no strong 
matches left in the SKG, weak matches are round for any 
remammg SKG members and joined to them m CIGs (steps 
722-725). 

At this stage, ail CIGs are built, Thev must now be 
■examined to determme what neeas to be done to these 
records so that the databases are synchronized, i.e. wnether 
the records in the CIGs need to be added, deleted or changed 
ID the two databases. First step is determinmg tne CIG_ 
I'YPH which represents the relation between the records. 
The following CIG types are defined, all using a 3 -digit 
number that represents values found for A_DAiABASh, 
History File, and B Database, respectively: 

X. OOl—record is '^new" in the B_DArABASE 

2. 010 — record is present in Histor>, but absent in both 
A_DaUbase and B_Databases 

3. 100 — record is "new' in the A_Database 

4^ 101 — record is ^*new" in both A_Database and 
B_DArABASE; same in both 

5. 102 — record is ''new" m both A^Databasc and 
D_DArABASE; different in each (condict) 

6, UO— record deleted from B_DATABASE 
7 Oil — record deleted from A_Databa.se 

8. 012 — record deleted from A_Database and changed on 
B„DA1ABASH (DEL vs CHANGE condict) 

9_ 210 — record changed onA_Database and deleted from 
B_DArABASE(DEL vs CHANGE condict) 

10. Ill — record unchanged since previous synchroniza- 
tion 

11. 112-H:ecord changed on B_DATABASE only smce 
previous syachronization 

12. 211 — record changed on A__Database only since 
previous synchromzatioa 

13. 212 — record changed identically on both since pre- 
vious synchronization 

14. 213 — record changed differendy on each since pre- 
vious synchronization (conflict) 

15, 132 — a conflict (102 or 213) was resolved by forming 

a compromise value; Update both 
16. 13F— created when a 132 Update both CIG is Fanned 

into the B^DAJABASE 
FIGS. 19Aand 19B show ihe method used for selling all 
except ihe last two CIG_Types which are set in other 
operations. 

Four of the CIG types assigned above involve conflicts: 
102^ 213, 012, and 210. Conflicts are those instances where 
a specific conflict resolution rule chosen by the user or set by 
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default, or ihe user s case by case decision, musi be used to 
determine how ihe records iicjm ihc daubaijes shouid be 
synchronized. CIG types 012 and 210 are cases where a 
previously synchrooized record is changed on one side and 
deleted on the other. In the prctcrrcd embodiment, such 
conflicts are resoived according lo the rule that CHANGE 
overrules the DELETE. So the net result for CIG type 012 
is 10 add a new record to the A_Database lo match the 
record in the BJATABASE. The reverse is true for CIG 
lype 210, where a new recort) is added to the B_Database. 
In an alternate emhodmient, the user may he allowed to 
register an automatic prcrcrcncc tor how to resolve such 
conflicts or decide on a case -by-case basis a conflict reso- 
lution option. 

The other two conflict types — 102 and 213 — are resolved 
in the preferred embodiment according to the Conflict 
Resolution Option established by the user. First, the user 
may choose to ignore the conflict. This option leaves all 1(12 
and 213 contiicts unresolved. Every time synchronization is 
repeated the conflict wiU be detected again and ignored 
again, as long as this option remains m effect and as long as 
the conflicting records are not changed by other means. 

The user may choose to add a new record to each of the 
iwo databases. This option resolves 102 and 213 conflicts by 
adding the new A_Record to the B ^Database, and adding 
the new B__Record to the A_Database. This option is 
implemented by breaking a 102 CIG mto two separate CIGs 
(types 100 and 001) and a 213 CIG into three separate CiGs 
(types 100, 010. and 001), Subsequent processmg of those 
descendant CIGs causes new records to be added across and 
stored in the Histor>' File. 

Ite user may elect that A_Database records should 
always trump or win over B database records. This option 
is implemented by changmg the CIG type to 211 — the 
processing during unloading the records changes the record 
value m the H_Databasc to mau:h the current record value 
mthcA Database. 

The user may elect that D_Database records should 
always trump or win over B^databasc records. This option 
is implemented by changmg the CIG type to 112 — the 
processing during unloading die records changes the record 
value in the A^JDatabasc to matcti the current record value 
in the B__Databasc, 

The user may choose to be notified in case of any conflict. 
The user is noufied via a dialog box 30, shown m FIG. 20, 
whenever a CIG type conflict of 102 or 213 arises. The 
dialog box shows the record that is involved in the conflict 
31. It also shows the A^Database 32 and B_Database 33 
values for all conflicting fields, in a tabular display, with 
Field Names appeanng in the left column 34. A dropdown 
list (not shown) in the lower left hand corner of the dialog 
37, offers a loial of three choices — add, ignorcj and update. 
The use may choo.sc to add new records or ignore the 
conflict. The user may also choose that the A_Recorri or 
R_Rccord should be used to update the other record. The 
user may also decide to create a compromise record by 
choosing values of different flelds and then choosing update 
option. In this case, the CIG type is changed to 132, which 
results m an updating both databases wiih the new rctjurd 
compromise record 

When the user has chosen lo be notified in case of conflict, 
if the user chooses to ignore conflict or that either the record 
of the A__D diabase or ihc B_DArABASE should win, the 
CIG type IS left as a conflict CIG lype (102 or 213) and a 
separate CunfliU Resolution Choice is stored in the FLAGS 
word associated with each CIG member. 

The final step in setting CIG_Types is the process for 
dealing with difficulties which arise from exclusion lists, for 
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example, in a tnpie Recurring Master CJG, suppose the 
History File Recurnng Master does mi have any cxciudtd 
instances. The A_ReL33fci lias the following exclusion list. 

12/1/96, 12/S/96 
Tlic B__R.ccorci has the following cxchisiuu list. 

1/1/97, 1/8/97, 1/15/97, 1/22/9^7, 1/29/97 

If couiparisou of the Recurring Masters includes coinpar- 
ing exclusion list Field Values, this set of changes would 
cause the Synchronizer to report a CIG type 213 conriict. 

If the Conflict Resolution Option is set to A__Database 
record wins, t&en the outcome prescnbed by the Synchro- 
nizer would be for the A_Database to keep its exclusion list 
as IS and for the B_Database to make its exclusion list 
match that of the A_Dalabasc- 

Thc result would be tn have a lot of duplicate entnes in 
both Databases. The A__Database would have five duplicate 
entries in January 97 — that is the hve unmodified Recumng 
Master instances, plus the five modified instances added 
across from B_Database to A__Database, The B_Database 
would have five duplicate entries in January 97, since 
syncfarooization has wiped out the five exclusions that were 
previously recorded in the B^Dat^base exclusion list. 

Two steps are implemented for deahng wiih this proolem. 
First, the COMPARE function docs not take into account 
exclusion hst differences when comparing recumng records. 
Second, referring to FIG. 21, any new exclusions added cn 
to one recurring record will be added to the other record. The 
merging of exciusion lists is done regardless of any updates 
or conflicts, even unresolved conliicts, between the 

A_Database and B Database copies of a Recurring Master. 

One exception is for CIG type i02 conilict which is left 
unresolved where Exclusion lists are not merged, because 
the user has chosen to leave those records as they are. 

Id most cases where it is necessary to merge exciusion 
lists, the CIG types and/or the Conflict Resolution Choice to 
arrange for all necessary updates to be performed during, the 
unloading pha.ses of synchronization. 

First, Al.Databasc and B„Databasc records' exclusion 
lists are compared. In case of databases which do not permit 
recTimne items» the exclusion list of the Synthetic Master is 
compared to the recurring record of the other database (step 

852) . If there is no difference, then nothing is acne (step 

853) . If there are dilTercnccs, (hen it is determined which 
exclusions appear only in one record. This cnmpansnn 
always yields one of the following scenarios: (I) ail onc- 
iidc-only Exclusions are on the A ^Database (so Exclusions 
should be added to the B_JDatabasc); (2) aU one-side-oniy 
Exclusions are on the B_I)atabas6 (so Exclusions should be 
added to the A_Databasc); and (3) there arc onc-sidc-oniy 
ExcliLsions on both sides (so Exclusioas should be added to 
both databases). 

In each of these cases a separate lable is ased to look up 
instructions, for how to handle each specific situation (FIGS. 
22-24). The tables cover all possible combinations of pre- 
vious CIG types and outcome codes with all possible 
excltLsion list changes (new and different exciu.sions added 
on A_Database, or ou B_Database, or on both sides). HG. 
22 table is used in case of scenano L FIG. 23 table is used 
in case of scenario 2. FIG. 24 table is used in case of scenario 
3 (FIG. 21 steps 854-«56). 

The analysis of records is now complete, and the records 
can be unloaded into their respective databases, including 
any additions, updates, or deletions. However, prior to doing 
so, the user is asked to canOrm proceeding with unloading 
(FTG. 3, step 108-109). Up to this point, neither of the 
databases nor the History File have been modiHed. The user 
may obtain through the Translation Engine's User Interface 
vanous informaiion regarding what will iraospirc upon 
unloading. 
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If the user ctiooses lo proceed with synchronization and to 
unload, ihc records art Ihen uniuaded in order into the 
B_Dat;ibase, the A_Darabase and the History File. Tiie 
Unloadcr moaules 6.10 of the Translators 5,9 pertorm the 
unioadmg tor tbc databases. The Synchronizer creates the 
History Fiie and unloads the records into it. The Control 
Module 2 of the Translation Engine i first inslracts the 
B_Translator to unload the records frorn Workspace into the 
B^Database. Referring to FIGS. 25Aand25B, for each CIG 
fo be uuloaded (determmeci in steps 902-907), ba.$ed on the 
CfG_TYPE ana which database it is unloading into (i.e., A 
or B), the unioadcr looks up in the table in FIGS. 26A-26D 
the outcome that must be achieved by unioadmg — that is, 
whether to update, delete, add, or skip (Leave _Arone) (step 
908). In steps 909-913, the unioader enforces date range 
restriaion for a database subject to date range. The user may 
beiect, or a selection may be made by default, whether lo 
enforce the date range sternly or leniently fn case of stem 
enforcement, ail records outside of the current date range 
woaid be deleted, iTiis is usetul for computers with small 
storage capacity. In case of lenient enforcement, the records 
are left untouched. 

Based on the result obtaiaed from iooicmg up the nnioad- 
:ng outcome in the table, the unioader then either adds a new 
record (steps 920-926), deletes an existing record (steps 
i? 14-919), or updates an existmg record (steps 927-933). It 
should be noted that because we only update those fields 
which need to be updated (step 928)» the he ids which were 
sanitized but need not be updated are not unloaded, 
ilierefore, the values m those lieids remam in unsanitized 
form m the database. 

Referring to step 914, m some Applications when a 
Rccurrmg Master must be added or updated, the record may 
have to be fanned out despite the abdity of the Appiication 
to support recurring records. For example, the Schcdulc+ 
Translator is generally able to put almost any Rccumng 
Master Item into Schedule + without fanning, but there arc 
some exceptions. The Scheduler Translator uses one Sched- 
ule section to handle all appomtmcnts and events. For 
appointments, almost any recurrence pattern is allowed, but 
tor events the only allowable true repeat type is YEARLY. 
DAILY recurrmg events can be dealt with by being trans- 
lated into Schedule + multi-day events which arc not recur- 
ring but extend over several days by settmg the EndDatc 
some time alter the Start Date. But for the DAILY case taerc 
arc restrictions. In particular exclusions m the midst of a 
multi-day Schedule-*- event cannot be created. So the Trans- 
lator decides that if section type is ToDos or the item is a 
non-Evcni Appointment, then the record need not be fanned 
out. But if item is a YEARLY or DAILY with no exclusions 
then it can be .stored a.s a Schcdule+ yearly or daily event. 
Otherwise, it must be fanned. 

Referring tn FTGS. 27A and 27R, .step,s 9S(X-984 set out 
the preferred embodiment of fanning recurring records that 
must be updated. Ail cases fail within three scenarios, shown 
in HG. 29. 

In the first scenario a record which is a Recurring Master, 
and its counterpart in the other database is a Recurring 
Majjler, must be fanned now for its own databaia; (steps 
951-959). If the CIG.TYPE of the record is 132 (i.e. update 
both record;*), then it is changed lo 13F which is a special 
value specifically for this situation (step 951). For odicr 
CIG_Types, the CIG is broken into three singielon and 
given CIG_Types signifying their singleton status. In both 
of these cases, the fuDclion Fanmng__For_Add (steps 
9S6-996, desCTibed below) is called. 

[n the second scenario, the record was fanned previously 
and is going to be fanned now also. First, the dates of the 
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instances are recoraed in a temoorary date arrav (steps 
961-963) This array is comparea to an arrav of the tanned 
instances of the recurrence paitern ot the CIG Recunin? 
Master trom the other database tsteps 965-966). The dates 
which are not in the arrav ol:' fanned instance are marKed for 
deletion (step 967). The dates which are not m the temnorary 
date array should be added lo the unloading databases ana 
therefore new FIG records are created for those dates (steps 
968-973). The dates wnich appear m aoth arrays are com- 
pared to the Syntheuc Master and marxed accordiugiy fo: 
UPDArt or Uave_AIoae (steps 974-978). 

tn the third scenario, the record which was previously 
fanned should now be fanned also, i^c opposing database's 
record in this sccoano is also fanned instances, iliis is 
perhaps the most peculiar of the three cases. For example, a 
database may be able to handle muiti-day (i.e. daily 
recurnng) records but noi any exclusion dates for such 
items. Such database may be synchronized with another 
database which fans ail records in the following manner. A 
record representing a T-day vacation m the Planner section 
of the database is fanned out to form 7 individual vacation 
days in the other database. One instance is deleted in the 
aihcr dalaba.se. Upon syncnronizmg tne two databases. b;c 
the hrst databases ooes not does not Drovide for excaJ.sxon 
iists» the recorc) must now be faimed. 

la this scenario. Master Reairds m a CIG are marked as 
Garbage. Any FIG members attached lo the H_„Recora, if 
any, are also marked as Garbage. All lustaaces found lu tlie 
oppowng databaiie 's FIG are truned to singleton CIGs with 
CIG type 100 or 001 so ihai ihey will be ydded to the 
unioader's database when unloading is done, in this way the 
instances from one database is copied lo the database 
providing for recurring records. 

Steps 985-995 describe the Fanning„For_Add Funcuon 
which is used when outcome is to update or when the 
function is called by the Transiator fannmg for update^ For 
each instance generated by fanning out the recurring record, 
a clone of the Recurnng Master is created but excluding 
Rep__Basic and Rep„Excl field values and the unique ID 
field. All adjustable Date Fields (e.g. Start Date, End Date, 
and Alarm Date) are sei and bash values for the new record 
is computed. The new record is then marked as Fanned_ 
For__A or Fanned_For_B, as the case may be. This is then 
attached to the Recurnng Master Item as a FIG memt^er. 

Followmg unloading of the B_RECORDS, the Control 
Module 2 instructs the A^Traoslator to unload the 
A_Records from the Workspace (FIG. 3, step Ul). This 
unioadmg is done in the same way as it was done by the 
B_TraQsiator in case of Rebuild^Ali Translators which 
have to reconstruct the database, aU records which were 
loaded from the database but were not used in synchroni- 
zation are appended and unloaded as the Translator builds a 
new database for its Application. 

llic Control Module 3 next instructs the iJyncbronizcr to 
create a new History File (step 112), Referring to FIG. 28, 
for every CIG in the Work^acc, it is first dctcrmmcd which 
record should be unloaded to History File (steps 
1001-1003). In the next step, Excl_Oniy flag is checked, 
which is set by the Mcrge_ExclusioD_Xist logic (FIG. 
21-24). If that flag is set, a new record for unloading is 
created which has all fields taken from the History File 
record, except that the newly merged exclusion list is 
inserted into that record (step 1004). Before storing rhc 
record in the History File, ail Flag Bits in the Extended Index 
are cleared except the bit that indicating whether or not this 
is a recurring item (step 1005). The item is marked as a 
Hxstor>' File record to indicate its source. The CIG, FIG, and 
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SKG are reset. All the HASH values and 
Start&EndDate&Time wiii be stored- All ippticable uuique 
ID are also stored (Steps 1006-1009). The current record is 
then stored m the new History file (step 10101 If the current 
record is a RecutTins Master ror an ID-bearing FIG, we now 
store the whole FIG (i.e. ail Fanned Instances) in the HistDr>' 
rile, with the FIG linkage words set m the History File to 
hold the FIG records togetner (step lOllV Fanned instances 
which do not bear unique IDs are not stored in the History 
File smce they can be re-generated by merely fanning out the 
Recurring Master. 

Once ail records are unloaded, various information nec- 
essary lor identifying this Histor>' File ana for the next 
synchronization arc wmtca into the History Flic (step 1013). 

At this point Synchronization is complete. 

Applications, such as scheduling Applications, often have 
more than one database. Each of these databases are known 
as sections. Each of these sections contain different data and 
must be synchronized with their corresponding sections in 
other Applications. However, there is not necessarily a one 
to one relationship between sections of various Applications. 
For example. Application A may compnsc of the following 
sections: AppomtmenLs, Hnliday.s, Business Addresses, Per- 
sonal Addrcsse.s, and ToDo, Application B however may 
comprise of the following sections: Appointments, 
Addresses, To Do-Tasks, and ToDo-Calls, Althongh the gen- 
eral character of (he sections are the same, there is not a one 
to one relation between the sections of these two AppHca- 
lioos: AppuinLraems and Holidays in A contain the same 
type of data as Appointments in B; Business Addresses atid 
Personal Addresses in A contain the same type of data as 
Addresses in B; and ToDo in A contains the same type of 
data as ToDo-Tasks and To Do-Calls in B. Therefore, when 
synchronizing the sections of these two Applications, it is 
necessary to synchronize at least two sections of one Appli- 
cation with one section of another Application. 

The preferred embodiment peifonns this type of synchro- 
nization by providing for a number of section categories: 
Appointment, ToDo, Note, Address, and General Database. 
All sections of a particular Apphcation are studied and 
categorized according to this categorization. Therefore, in 
the above example of Application A, Appointments and 
Holidays are categorized Appointment type sections (or 
database). Business Address and Personal Address as 
Address type sections^ and To Do as a ToDo type section. 

For creating the map for mapping sections onto each 
other, an exact section match is always sought between 
sections of the two Applications. If not, one of the sections 
which were categorized as a section type is chosen to be the 
Main_Section among them. Other sections of the same type 
are referred to as subsections. All databases of the same type 
from the other Apphcation will be mapped onto the Main_ 
ScctioD. 

To properly synchronize from one time to the next, it is 
necessary to keep track of the source of records m the 
MainjScction. In the prctcrrcd embodiment, if a record in 
the Main^Section of the A__Applicadon does not come 
from the Main_Section of the B_Application. one of fields 
in the record, preferably a text field, is tagged with a unique 
code identifying the subsection which is the source of the 
record. This is the record's Origin Tag. AH records in the 
Workspace and the History File incmde a hidden internal 
field ca]led__subType which contains the unique subsection 
code. Main_Section^s field value in the preferred cmbodi- 
meat is zero so that it will not be tagged. When a record is 
loaded from a database into tlie Syuchronizauon Workspace, 
the lag IS stripped Ixom the TagBearer field and put in the 
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__subType field. If there is no tag, then the _subType is set 
to be tbe subtype of the present section. If the fagBearer 
field is mapped then wnen readme records into the Work- 
ipace the tag, if any, is stnpped from the TagBearer tie id 
value place it in _subtype. 

Conversely when unloading records trom the Workspace 
to a Database* the lagBcarcr licid is lagged by a tag ocing 
added if the record is not trom ihc Main_Scciion. 

A Fast Synchronization database is a database which 
provides a method of keeping track of changes, deletions, 
and additions to its records from one synchronization to the 
next. These databases speed up the synchronization process 
because only those records which have been modified need 
in be ioaded from the database. Since the majority of records 
loaded by regular Translators are unchanged records, far 
fewer records are loaded from the database into tbe Syn- 
chrunizer. 

Certain features are required for a database to be a Fast 
Synchronization database. The database records must have 
unique IDs and must have a mechanism for keeping track of 
which records arc added, changed, or deleted from synchro- 
nization to syncbronizaiion, including a list of deleted 
records. Unique IDs are requirea to accurately identify 
records over a period of lime. 

There are at least two ways to keep track of additions, 
changes, and deletions in a database. 

First, some databases maintain one Dirty bit per record 
which is a boolean flag that is set when a record is created 
or modified and is cleared when a function for cieanng Dirty 
bits is called. Some databases otfer a Clear DiityBit function 
that clears the bit of an mdividual record. Other databases 
offer a ClearDirtyUits function that clears the Dirty bits of all 
records in a database. Ihe record-specilic ClearDirtyBit 
ftmction allows the preferred embodiment to use the data- 
base itself to keep track of additions and changes. 

The global ClearDirtyBits funcdon forces the preferred 
embodiment to clear all Dirty bits at the conclusion of every 
Synchronization. Then as database edits arc made by the 
u.scr in between synchroniTations. the affected records arc 
marked as Dirty. When Synchronization is performed again, 
only the Dirty records are loaded. 

Second, some databases maintain a Date&Time staxnp of 
when the record was added or laii lime the record was 
modified. A Translator for such a database finds all records 
which were added or modified since the previous synchro- 
nization by searching for Date&Time stamps more recent 
than the Date^Ttme of the Last Synchronization. 

A Fast Synchronization database must also keep track of 
deletions. This is done by maintaining a list of deleted 
records which can be read by a Translator. 

A Translator sending Fast Synchronization database 
records to the Synchronizer provides only records which 
have been changed, deleted, and added since the previous 
synchronization. Therefore, unlike a regular database 
Translator, a Fast Synchromzation Translator does not pro- 
vide the Synchronizer with unchanged records. Moreover, 
unhke a regular Translator it provides deleted records, which 
the regular Translators does not. 

In order for such databases to be synchronized without 
resorting to trcadng them as regular databases, the Synchro- 
nizer transforms Fast Synchronization records from the 
Translator into the equivalent regular database records. 
These transformed records are then used by the Synchro- 
nizer in the synchronizadon. There arc two transformadons 
which arc necessary. First, the Synchronizer needs to trans- 
form deleted records received from the Fast Synch mm 7 a lion 
Translator into a regular database deletions. Second, syn- 



22 



chronizalioa aeeds to traosform lack of output by the Fast 
SyQchromzailoa Translator into unchanged records. 

The invention performs these transformations oy using 
the History File. During the Ikst synchronization, ail records 

5 in the Fast Synchroni2ation database are loaded mto the 
history file. As changes^ additions, and deletions are made to 
the Fast Synchronization database, during each of the sub- 
sequent synchronizations the same change, additions, and 
deletions are made to the History File, Therefore, the History 
File at the end of each subsequeai synchronization is an 
exact copy of the Fast Synchronization database. 

When a Fast Synchronization Translator supplies no input 
for a unique ID H_Record. the Synchronizer finds the 
corresponding H__RecoKi ia the Workspace and copies it 
into the Workspace as a record supph'ed as if it were loaded 
by the Fast Synchronization translator itself. 

Referring to FIG, 30, steps 105D-1051, the Synchronizer 
first verifies that there is an appropriate History File. 
Becaiise the Fast Synchronizing process relies heavily on the 
History File^ ii is imponant to ensure that the same history 

zo file as the last Synchronizauon is used. Moreover, the 
History File is the background against which the transfor- 
mation of the Translator outputs mio regular Translator 
outputs takes place. The History File keeps a date and unae 
stanap of the last synchronizaiion. Each of the Fast Synchro- 
's nizaiion database (if able to) and the Fast Synchromzatian 
Translator also stores the same date and time stamp. The 
time and date stamp is used because it is unhkely that 
another History File will have exactly the same time and 
date entry, for the same two databases. It also identifies when 

jO last the Fast Synchronizer database and the History File 
contained the same records. 

At the start of an incremental s>'nchromzation, the Syn- 
chronizer and the Fast Synchronization Iranslator compare 
date and time stamps. If time and date stamp synchroniza- 

35 tion parameters have changed since the previous 
synchronizaiion, then the synchronization proceeds from 
scratch (step 1052), In a s>Tichronization from scratch all 
records in the Fast Synchronization database are loaded into 
the History File. 

40 Fn the preferred embodiment, ail records supplied as Fast 
synchronizadon inputs have a special hidden field called 
_Delta, which carries a siagle-lelter value — 'D' for Delete 
or 'A' for Add and for Change. Records are loaded by the 
Fast Synchronizaiion Translator into the Workspace (step 

AS 1054). If necessary the records are mapped when loaded. 
Records which are marked as changes or additions are 
sanitized by the Translator for the other database, but deleted 
records are not because their field values are going to be 
deleted (step 1055). Orientation analysis (FIG. U) is per- 

50 formed on the records so that all deletions and changes to 
Fast Synchronization database records are joined with their 
History File counterparts in unique ID bearing CIGs (step 
HOT). 

All History File records and their CIGs are now exam- 
55 ined. If there is no corresponding record from the Fast 
syacfaronization database, it means that the record was 
unchanged. A clone of the record is made, labelled as being 
from Fast Synchromzation database, and joined to the 
H_Jlecord's CIG. At this point the deleted Fast synchroni- 
50 zation database records marked as deletions arc removed 
from CIGs (step 1109), The Fast Synchronization records 
marked as changed arc joined in doublcton CIGs. Those 
marked as additions arc singletons. At this point, the syn- 
chronization can proceed as if record of a unique ID bearing 
6a regular database were just loaded into the Workspace. 

Whenever we are loading from a Fast SyncbroniTation 
database, all records are loaded so that at the cad of 
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synchronization the history file wili be the same as the Fast 
Synchronization Database. Therefore, reterring to FIGS. 
31A and 31B, in order to perform date range limited 
bynchronizalion, the invention marks the records which fall 
outside the current and the previous date ranges. For a record 
marked as an addition, or during synchronizing from 
scratch, if the record falls outside the current date range, it 
is marked as Out_0f„Range (steps 1101 and 1153-1154). 
This record will be written into the History File but not into 
the other database or take part m the synchrom/ation. When 
the Fast Synchronization database records arc loaded from 
the History File, if they fall outside of the previous cJate 
range, liiey are marked as Bystander (steps 1152-1157). If a 
Bystander record forms a CIG with a Fast Synchronization 
record marked as a deletion or a change, the Bvslander is 
marked with a Garbage flag because its field values ser\'e no 
useful purpose any more: the record marked as DELETION 
should be deleted and the record marked as CHANGED 
should replace the Bystander H_Record (step 1162). 

H_Records for which there are no inputs are transformed 
in the same manner as before (steps 1164-1165). If a 
Bystander record falls within the current date range, u is 
equivalent to a regular database record coming into the 
current date range. Therefore, the H_Record is cloned and 
marked as a Fast Synchronizer record while the Bystander 
record is marked as Garbage (steps 1166-1171). Therefore, 
just like a new record of a regular database, it has no 
H Jecord counterpart. 

If the user selects to abort a synchronization or selects the 
option to ignore a conflict or contlicts m general, some of the 
records loaded from the Fast Synchronization database will 
not be accepted and recorded in the History File. Therefore, 
the Translator should provide that record again at the next 
synchronization. However, because Fast SynchromzaUon 
Translators supply only records which have been changed, 
deleted, or added since the previous synchronizadon, the 
records which were not accepted wii] not be supplied. 
Therefore, in the invention, Fast Synchronization Translator 
waits for an ackaowiedgement from the Synchronizer that 
the record has been accepted. 

In case no such acknowledgemeat is received for a record, 
the Translator needs to be able to provide that record again 
to the Synchromzer. If the database allows resetting indi- 
vidual Dirty bits, the Translator merely does not set that bit. 
If not, the Translator keeps a separate file in which it keeps 
a record of which Fast Synchronization records were not 
accepted. The file may contain the unique IDs of those 
records. The Translator then uses that file to provide the 
synchronizer with tbose records during the next synchroni- 
zation. 

Other embodiments are within the foUo\\ing claims. 



